In a previous post I talked a bit about variations and since it has been the most viewed post of the blog so far :D I wanted to talk a little more about it.

I’ve seen many searches as “force moss variations”, so I did this post to give a c# code to force moss variation propagation. The solution with the code and the test webpart can be downloaded here, you can use it freely, but I’d love if you let me know :).

We have a simple publishing portal, with three hierarchies “initial”, “secondary” and “third”, we have already created the hierarchies.

So we need to know how to propagate the hierarchies, so we go to the main page of our root hierarchy:

We see there is a menu item which makes what we want, so we’ll use .NET reflector to know which methods does it invoke…

Fist of all we have to identify where the Update Variations option is located, so we’ll open Microsoft.SharePoint.Publishing.dll using .net reflector.

Once opened, we’ll search Variations, and we will find UpdateVariationsAction as the first result, we are lucky ;)

We double click it to show the disassembly, and locate the UpdatePageVariationsLro class with its “Start”, “DoWork” and “UpdatePageVariations” methods (promising!):

When you look a the variations object model you’ll find there is no public method to propagate the changes because everything is internal, so it is a bit difficult to make and we will need to make use of reflection…

So I will create a class DeploymentWrapperHelper which will encapsulate the logic needed to interact with the variations:

We will create this global variables:

In the constructor of the class we will get the type for the deployment wrapper and the actual object to be used with reflection:

So once we have the foundation, we use this function to force the variation propagation, after a few attempts the easiest way to achieve the propagation is calling the Start method:

You can see that we create a list of VariationCreateUpdateError objects (I’ve taken the Create Generic Type Dynamically function from this post by Marcin Celej.), then the running operation job, then we configure the job.

Then we check if we the target variation pages are created, we need them to be created or the code will fail. I tried to create them by using the CreateVariations method of the Publishing Page class, but it failed with a file not found error and created inconsistencies in the variation propagation, so… the target pages must be created prior to run the code.

And the last part is to start the job, it will propagate the changes to the pages. I could make this work from a webpart, not from an external exe, I suppose it uses internally some kind of context object.

The code needed to get the variation settings is this:

So far, we have forced the variation propagation to all the variations, but how can we force the update for just one variation label? Here is the code:

You’ll notice that ugly “try-catch” block, it seems that the problem arises when the systems tries to update the status of the job, the variations get propagated ok and the variation systems continue to work, but the exception is thrown.

The main problem with both utilities is that we need to have the page created before running the code, but it might be useful for certain things since you don’t need to publish the page to update the variations, you can do it with the Update Variations, button, but this code can make the job when updating lots of pages.